xorg and openoffice.org started with a cleanup of their bug reports. It is really great that compared to 2-3 years ago major cores of the Debian OS in unstable are quite in sync with upstream. Thus it is easy to forward to upstream the interesting part of bugs. The linux-2.6 bugs count reached that weekend almost 850 open bugs. Seeing that it gets unmanageable I'll decided to get it down to a target of 100 bugs. I'll blog from time to time about the progress. The process consists of pinging quite some bug reports against old Linux images and closing a huge swap of duplicate or no longer relevant bug reports. I expect the signal to noise ratio getting better once the bug count gets denser. The current side effect was to forward 1 patch upstream and to get 2 easy low hanging fruits fixed in latest linux-2.6 trunk. Thanks to enabling CONFIG_BLK_DEV_IO_TRACE trunk gains support for the blktrace(8). blktrace does direct IO block layer tracing - see also blktrace guide.

E\sT\N \f Symbol t\0 f

Once you start typing such strings blindly, you know that you have been generating lots of graphs with xmgrace. :)
LaTeX equivalent would be

E_T \tau f

The cardinal reason for the switch is collaboration: git scales. During my bzr usage time of the last year i observed the following shortcomings of bzr:

Speed - This improved a bit lately but not enough for my q&d usage.

Documentation - Beside the obvious "svn-style" commands the usage of the other commands isn't obvious and the man pages lack examples. git is not perfect in that regard, but you quickly find typical usage pattern on wiki tutorials or on many google hits.

Pager - On big diff output bzr doesn't pipe that to pager^Wless. I consider that as a big usability bug.

Branches - I recently learned that a bzr repository corresponds to a git repo with just one branch. This seems strangely complicated. I really love to have different branches ready to checkout in my pwd . This short-coming blocks cooperation as i'm not confident enough to fetch random changes from bug reporters in my own branch.

Minor Nitpicks:
* Push command - Defaults on the non-obvious old sftp protocol. Worked with rsync on some very ancient version.
* Repo format - Changes on every major upgrade.
* Patchlevel - Probably for svn compat reason the chosen default patchlevel is -p0 not -p1.

Latest initramfs-tools repo is available at:
git clone git://git.debian.org/git/kernel/initramfs-tools.git Thanks to tailor it is now possible to move from different version control systems. For git as target repository it is recommended to use latest upstream either directly via darcs or at least install the unstable version. The etch version throws strange python backtraces.

The e2fsprogs package in Etch features the ext[23] resize2fs, see it in action on a mounted /usr partition:

nancy:/root# egrep usr /proc/mounts 
/dev/mapper/nancy_vg1-usr /usr ext3 rw,noatime,nodiratime,data=ordered 0 0

Now let's extend a bit that logical volume:

nancy:/root# lvextend -L+700M /dev/nancy_vg1/usr       
Extending logical volume usr to 4.68 GB
Logical volume usr successfully resized

Next easy step is to invoke resize2fs

nancy:/root# resize2fs /dev/nancy_vg1/usr 
resize2fs 1.40-WIP (14-Nov-2006)
Filesystem at /dev/nancy_vg1/usr is mounted on /usr; on-line resizing required
old desc_blocks = 1, new_desc_blocks = 1
Performing an on-line resize of /dev/nancy_vg1/usr to 1227776 (4k) blocks.
The filesystem on /dev/nancy_vg1/usr is now 1227776 blocks long.

Update: Mika of course already blogged about ext3 online resizing. Bug #400797 is a very good reason not to use ext2resize. I remember a post from Theodore Tso on it's bad code quality. Don't trust it.

• Fistognosticated - Ella Baila
• Ellen Allien - Crosstown Rebels
• 4twenty - Wenn der Beat rollt
• Don Choa - La verit blesse
• Ricardo Villabos - Fiezheuer Zieheuer
• J rgen Paape - Take this
• Oliver Hacke - Baked Bean Mix
• Henrik Schwarz - Leave my head alone brain rmxs
• Ellen Allien & Apparat - Bubbles
• Tiefschwarz - Issst (Nathan Fake remix)
• Lina - I'm not the enemy

Yeah i've danced all night in Florence on Ellen Allien sounds, explains why she shows up twice - great djane. :) Meike, thanks for this funny "meme". By the way out of lazy web how did you fix the blosxom timezone toppost trouble? (urggs got title year wrong) update: *doing* *doing* *doing* everywhere ;)

Three letters corporations don't inspire confidence (junk code, big tactics, ..). Nevertheless Thinkpads i will miss you. My current workhorse is a x41 Thinkpad. The default model has a bad battery life. Yeah the x40 are cool and with much better battery life out of the box, but they need this mad atheros binary hal junk (the ath free replacement goes nowhere right now :(. No i won't taint the running kernel. So just buy a battery upgrade and be happy.
In August cycling i got badly hit by a car. Making a cool stunt on asphalt with a crashed helmet and hurt everywhere. The laptop being unprotected in backpack. No complaints from the X41. Throw it across rooms and it happily boots. Exposing it to dust did not cause any high pitch noise like some earlier Vaio.
As Thinkwiki will tell you the Hitachi hdd are not really worth to put data on them. I got mine easily exchanged 2x. I wouldn't care less thanks to git, imapd and frequent backups.
As you can probably imagine the story of unbreakable doesn't stop here, but i won't leak current experiences "nancy" had to endure. Anyway i wanted to join in the Thanks to all the peoples that make Debian the pleasure to hack and work on! Big props to the Release Team for coordinating the fine Etch product.

2.6.18-4 was uploaded on Sunday and should be soonest available after dinstall run for most archs. The ia64 build failure is fixed in svn thanks to Thiemo Seufer (ths). alpha is waiting for an updated gcc (see patch in #397139). s390 is currently broken by vserver, patch is awaited soon. linux-latest will be updated tomorrow and expect soon a 2.6.18-5, once those issues are cleared.
linux-image-2.6.18-2- is the Debian kernel team stabilized kernel. Please install it and report eventual bugs. If you know a patch from Linus git tree that fixes your problem even better name it. Thanks for your testing!
We had been quite busy to feed stable with patches that fit the Documentation/stable_kernel_rules.txt. Goodies like Xen, drm-i965 or ahci backport are shared with Fedora Core 6 release. Beyond that for example the r8169 patch series or ccisss support for 2 TB volumes got backported. Out of reach are destabilizing patches like the new 2.6.19 ACPI patches. Further backports are planed for the SUSE reiserfs 2.6.19 patches and vorlon has a fix in the pipe for the vga console driver on alpha.

History
For the sarge release official kernel-images from the newly formed Debian kernel team came together with initrd-tools. initrd-tools Maintainer was jbailey. It saw some care from tbm, vorlon and me before the actual release. Remembering the flow of bugs and installation-reports it accounted for a huge number of install failures plus lacked many features the Red Hat mkinitrd had. Ubuntu got hit more directly as hoary released with a newer kernel than 2.6.8 and due to the initrd-tools devfs requirement.
initramfs-tools originated out of the need of a direct replacement. Inspired by an initramfs OLS talk jbailey had the goals of boot-time hardware detection using the nice and neat features the Linux 2.5 branch incorporated: The sysfs support of the Linux drivers allows an neat userspace daemon aka udev to coldplug them. udev is the replacement of a maze of slow shell scripts called hotplug package. The second big feature is the new initramfs format (the curious may want to read Documentation/filesystems/ramfs-rootfs-initramfs.txt of any current linux-2.6 source). For a boot loader initramfs or initrd is the same fish. The smaller and more efficient in kernel code makes the difference. The initramfs gets loaded much earlier, due to being only an cpio archive and not an fs allowing it to completely rule the rootfs search and mount. One initial assigned spec had the name "easy NFS root". The LTSP guys joined in and showed interest in incorporating their work.
Technology
initramfs-tools got default in Debian together when the first common linux-2.6 (2.6.15) package reached etch, powered all the Ubuntu releases from Breezy on and is used by the grml live-cd. Since archive inclusion almost a year ago it got much better support of all the various linux boot parameters (see man initramfs-tools or the "official" Documentation/kernel-parameters.txt), keeps an backup initrd around and has better block-based bootloader support (lilo, ..). klibc has been ported to _all_ the Debian release archs where it is in use and compiles fine on m68k and sh.
The initramfs-tools early userspace is very flexible based on it's hooks for initramfs build and boot. Thanks to alphix for the help on shaping the building blocks. There are initramfs hooks in cryptsetup, evms, dmraid, firmware-qlogic, lvm2 multipath, mdadm, usplash, .. Reviewers, uploaders and sponsors included fs, jbailey and Sesse. Most of the time it is sufficient and easy to test changes in qemu images (See slides workshop early userspace). The best wish of an early userspace is not to be remarked - aka happy booting. Nevertheless thanks a lot for the public support: Achieving Xen Disk encryption support in Etch, Popping my initramfs cherry, ..
Future
The latest initramfs-tools release seems almost ready for the upcoming etch release. The bug reports coming over from installation-reports are happily rare. Although the uuid based fstab generation solution is not yet integrated in the debian-installer. There are one or two known nitpicks left-over in the bts plus one bugger: udevsettle may exit to early, when not all the discs are ready for use. For grub there is a fail-over net, but which does not account for a to early md or lvm2 boot hook. Future initramfs-tools development will focus on an optional small klibc based Modules=dep hand walking /sys initramfs generation allowing better embedded support. grub2 will present run-time assembly challenges for the initramfs.

I spent Monday to Friday in Vienna, visiting some friends from school. Quite a few people I know moved to Vienna after finishing high school (or later), so I thought I'd go there for a few days to meet up with some of them. On Monday evening, I gave a talk at Debienna, the Debian group in Vienna. I started with one of my presentations about quality issues in free software, but given that we were a small and informal group we often interrupted the presentation for discussions. During these discussions the generic issues I mentioned were applied to Debian and we discussed a number of problems in Debian and what we could do about them. I think it was quite interesting, although it stretched the talk quite a bit and some people were getting restless towards the end. This was also the first talk I gave in German. I originally planned to give it in English but then thought I'd try to do it in German. It went pretty well, although I couldn't think of a number of words on the spot and just used English words instead. (Not counting technical terms, obviously, which I didn't even try to translate.) On Tuesday and Wednesday, I mostly stayed in bed working on my laptop. This was, after all, only a pseudo-holiday and I had plenty of work to do. On Wednesday evening, Veronika (the friend I was staying with), maks (Maximilian Attems) and I went to B72 to see a concert by Das Bo. There was also a DJ from Waxos who was great. Das Bo was pretty good too, although he talked too much crap between songs. On Thursday, Veronika and I went shopping and I bought lots of new clothes. Friday morning, just before leaving, I met with Stefan Holek to do an interview about release management in Plone for my research. He raised a number of really interesting issues.

I’m not much of a coder, but as everybody, I have several small scripts to do miscellaneous tasks. Over time, I’ve postponed repeteadly to put them under Subversion, which was my VCS of choice, since I didn’t like the “one repo for all” approach, and creating a repo for each of them felt like too much work. A few weeks ago I tried bzr, and have managed to put several of these scripts under its control since; one repo for each script makes sense to me when they’re very easily created, and data and metadata live together. (I realize other distributed VCS have this as well, but bzr was the one I tried first, knowing it’d be the one that would have more chances of me liking it.) I’ve made publicly available those scripts which I think somebody could find useful, here (mirror in gluck). The one I’m more interested in publicizing is grep-archive, a wrapper over grep-dctrl formerly known as grepd. Since it works over a mirror-like directory tree, I’ll try to write a script that creates one and fills it with symlinks pointing to Packages files under /var/lib/apt/lists, so that it’s easier to start using it. Another one worth mentioning is good old bug-reply-to.vim, which I remembered to put in bzr yesterday after kernel-team member Maximilian Attems expressed on IRC his frustration by bug submitters not CCing the bug in their replies to him. I’ve also taken chance to improve it a bit, most notably adding support for adding whatever is in the From field to the Reply-To (formerly the address would have to be explicitly passed as an argument, which was suboptimal if one uses more than one address), and documenting it a bit. NP: Fangoria, Interior de una nave espacial abandonada